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Abstract 


The Dynamic Host Configuration Protocol (DHCP) provides a framework 
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r passing configuration information to hosts on a TCP/IP network. 


DHCP is based on the Bootstrap Protocol (BOOTP) [7], adding the 
capability of automatic allocation of reusable network addresses and 
additional configuration options [19]. DHCP captures the behavior of 
BOOTP relay agents [7, 23], and DHCP participants can interoperate 
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th BOOTP participants [9]. Due to some errors introduced into RFC 
31 in the editorial process, this memo is reissued as RFC 1541. 
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1. Introduction 


The Dynamic Host Configuration Protocol (DHCP) provides configuration 
parameters to Internet hosts. DHCP consists of two components: a 
protocol for delivering host-specific configuration parameters from a 
DHCP server to a host and a mechanism for allocation of network 
addresses to hosts. 


DHCP is built on a client-server model, where designated DHCP server 
hosts allocate network addresses and deliver configuration parameters 
to dynamically configured hosts. Throughout the remainder of this 

document, the term "server" refers to a host providing initialization 
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parameters through DHCP, and the term "client" refers to a host 
requesting initialization parameters from a DHCP server. 


A host should not act as a DHCP server unless explicitly configured 
to do so by a system administrator. The diversity of hardware and 
protocol implementations in the Internet would preclude reliable 
operation if random hosts were allowed to respond to DHCP requests. 
For example, IP requires the setting of many parameters within the 
protocol implementation software. Because IP can be used on many 
dissimilar kinds of network hardware, values for those parameters 
cannot be guessed or assumed to have correct defaults. Also, 
distributed address allocation schemes depend on a polling/defense 
mechanism for discovery of addresses that are already in use. IP 
hosts may not always be able to defend their network addresses, so 
that such a distributed address allocation scheme cannot be 
guaranteed to avoid allocation of duplicate network addresses. 


DHCP supports three mechanisms for IP address allocation. In 
"automatic allocation", DHCP assigns a permanent IP address to a 
host. In "dynamic allocation", DHCP assigns an IP address to a host 
for a limited period of time (or until the host explicitly 
relinquishes the address). In "manual allocation", a host’s IP 
address is assigned by the network administrator, and DHCP is used 
simply to convey the assigned address to the host. A particular 
network will use one or more of these mechanisms, depending on the 
policies of the network administrator. 


Dynamic allocation is the only one of the three mechanisms that 
allows automatic reuse of an address that is no longer needed by the 
host to which it was assigned. Thus, dynamic allocation is 
particularly useful for assigning an address to a host that will be 
connected to the network only temporarily or for sharing a limited 
pool of IP addresses among a group of hosts that do not need 
permanent IP addresses. Dynamic allocation may also be a good choice 
for assigning an IP address to a new host being permanently connected 
to a network where IP addresses are sufficiently scarce that it is 
important to reclaim them when old hosts are retired. Manual 
allocation allows DHCP to be used to eliminate the error-prone 
process of manually configuring hosts with IP addresses in 
environments where (for whatever reasons) it is desirable to manage 
IP address assignment outside of the DHCP mechanisms. 


The format of DHCP messages is based on the format of BOOTP messages, 
to capture the BOOTP relay agent behavior described as part of the 
BOOTP specification [7, 23] and to allow interoperability of existing 
BOOTP clients with DHCP servers. Using BOOTP relaying agents 
eliminates the necessity of having a DHCP server on each physical 
network segment. 
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1.1 Related Work 


There are several Internet protocols and related mechanisms that 
address some parts of the dynamic host configuration problem. The 
Reverse Address Resolution Protocol (RARP) [10] (through the 
extensions defined in the Dynamic RARP (DRARP) [5]) explicitly 
addresses the problem of network address discovery, and includes an 
automatic IP address assignment mechanism. The Trivial File Transfer 
Protocol (TFTP) [20] provides for transport of a boot image from a 
boot server. The Internet Control Message Protocol (ICMP) [16] 
provides for informing hosts of additional routers via "ICMP 
redirect" messages. ICMP also can provide subnet mask information 
through the "ICMP mask request" message and other information through 
the (obsolete) "ICMP information request" message. Hosts can locate 
routers through the ICMP router discovery mechanism [8]. 


BOOTP is a transport mechanism for a collection of configuration 
information. BOOTP is also extensible, and official extensions [17] 
have been defined for several configuration parameters. Morgan has 
proposed extensions to BOOTP for dynamic IP address assignment [15]. 
The Network Information Protocol (NIP), used by the Athena project at 
MIT, is a distributed mechanism for dynamic IP address assignment 
[19]. The Resource Location Protocol RLP [1] provides for location 
of higher level services. Sun Microsystems diskless workstations use 
a boot procedure that employs RARP, TFTP and an RPC mechanism called 
"bootparams" to deliver configuration information and operating 
system code to diskless hosts. (Sun Microsystems, Sun Workstation 
and SunOS are trademarks of Sun Microsystems, Inc.) Some Sun 
networks also use DRARP and an auto-installation mechanism to 
automate the configuration of new hosts in an existing network. 


In other related work, the path minimum transmission unit (MTU) 
discovery algorithm can determine the MTU of an arbitrary internet 


path [14]. Comer and Droms have proposed the use of the Address 
Resolution Protocol (ARP) as a transport protocol for resource 
location and selection [6]. Finally, the Host Requirements RFCs [3, 


4] mention specific requirements for host reconfiguration and suggest 
a scenario for initial configuration of diskless hosts. 


1.2 Problem definition and issues 


DHCP is designed to supply hosts with the configuration parameters 
defined in the Host Requirements RFCs. After obtaining parameters 
via DHCP, a host should be able to exchange packets with any other 
host in the Internet. The parameters supplied by DHCP are listed in 
Appendix A. 
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Not all of these parameters are required for a newly initialized 
host. A client and server may negotiate for the transmission of only 
those parameters required by the client or specific to a particular 
subnet. 


DHCP allows but does not require the configuration of host parameters 
not directly related to the IP protocol. DHCP also does not address 
registration of newly configured hosts with the Domain Name System 
(DNS) [12, 13]. 


DHCP is not intended for use in configuring routers. 

1.3 Requirements 
Throughout this document, the words that are used to define the 
significance of particular requirements are capitalized. These words 
are: 


o "MUST" 


This word or the adjective "REQUIRED" means that the 
item is an absolute requirement of this specification. 


o "MUST NOT" 


This phrase means that the item is an absolute prohibition 
of this specification. 


o "SHOULD" 


This word or the adjective "RECOMMENDED" means that there 

may exist valid reasons in particular circumstances to ignore 
this item, but the full implications should be understood and 
the case Carefully weighed before choosing a different course. 


o "SHOULD NOT" 


This phrase means that there may exist valid reasons in 
particular circumstances when the listed behavior is acceptable 
or even useful, but the full implications should be understood 
and the case carefully weighed before implementing any behavior 
described with this label. 
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O " MAY " 
This word or the adjective "OPTIONAL" means that this item is 
truly optional. One vendor may choose to include the item 
because a particular marketplace requires it or because it 
enhances the product, for example; another vendor may omit the 
same item. 
1.4 Terminology 
This document uses the following terms: 


o "DHCP client" 


A DHCP client is an Internet host using DHCP to obtain 
configuration parameters such as a network address. 


o "DHCP server" 


A DHCP server is an Internet host that returns configuration 
parameters to DHCP clients. 


o "BOOTP relay agent" 
A BOOTP relay agent is an Internet host or router that passes 
DHCP messages between DHCP clients and DHCP servers. DHCP is 
designed to use the same relay agent behavior as specified in 
the BOOTP protocol specification. 

o "binding" 
A binding is a collection of configuration parameters, including 
at least an IP address, associated with or "bound to" a DHCP 
client. Bindings are managed by DHCP servers. 


1.5 Design goals 


The following list gives general design goals for DHCP. 


o DHCP should be a mechanism rather than a policy. DHCP must 
allow local system administrators control over configuration 
parameters where desired; e.g., local system administrators 
should be able to enforce local policies concerning allocation 
and access to local resources where desired. 
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o Hosts should require no manual configuration. Each host should 
be able to discover appropriate local configuration parameters 
without user intervention and incorporate those parameters into 
its own configuration. 


o Networks should require no hand configuration for individual 
hosts. Under normal circumstances, the network manager should 
not have to enter any per-host configuration parameters. 


o DHCP should not require a server on each subnet. To allow for 
scale and economy, DHCP must work across routers or through the 
intervention of BOOTP/DHCP relay agents. 


o A DHCP host must be prepared to receive multiple responses to a 
request for configuration parameters. Some installations may 
include multiple, overlapping DHCP servers to enhance 
reliability and increase performance. 


o DHCP must coexist with statically configured, non-participating 
hosts and with existing network protocol implementations. 


o DHCP must interoperate with the BOOTP relay agent behavior as 
described by RFC 951 and by Wimer [21]. 


o DHCP must provide service to existing BOOTP clients. 


The following list gives design goals specific to the transmission of 
the network layer parameters. DHCP must: 


o Guarantee that any specific network address will not be in 
use by more than one host at a time, 


o Retain host configuration across host reboot. A host should, 
whenever possible, be assigned the same configuration parameters 
(e.g., network address) in response to each request, 


o Retain host configuration across server reboots, and, whenever 
possible, a host should be assigned the same configuration 
parameters despite restarts of the DHCP mechanism, 


o Allow automatic assignment of configuration parameters to new 
hosts to avoid hand configuration for new hosts, 


o Support fixed or permanent allocation of configuration 
parameters to specific hosts. 
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2 


Protocol Summary 


From the client’s point of view, DHCP is an extension of the BOOTP 
mechanism. This behavior allows existing BOOTP clients to 
interoperate with DHCP servers without requiring any change to the 
clients’ initialization software. A separate document details the 
interactions between BOOTP and DHCP clients and servers [9]. There 
are some new, optional transactions that optimize the interaction 
between DHCP clients and servers that are described in sections 3 and 
4. 


Figure 1 gives the format of a DHCP message and table 1 describes 
each of the fields in the DHCP message. The numbers in parentheses 
indicate the size of each field in octets. The names for the fields 
given in the figure will be used throughout this document to refer to 
the fields in DHCP messages. 


There are two primary differences between DHCP and BOOTP. First, 
DHCP defines mechanisms through which clients can be assigned a 
network address for a fixed lease, allowing for serial reassignment 
of network addresses to different clients. Second, DHCP provides the 
mechanism for a client to acquire all of the IP configuration 
parameters that it needs in order to operate. 


DHCP introduces a small change in terminology intended to clarify the 
meaning of one of the fields. What was the "vendor extensions" field 
in BOOTP has been re-named the "options" field in DHCP. Similarly, 
the tagged data items that were used inside the BOOTP "vendor 
extensions" field, which were formerly referred to as "vendor 
extensions," are now termed simply "options." 


DHCP defines a new '*client identifier’ option that is used to pass an 
explicit client identifier to a DHCP server. This change eliminates 
the overloading of the ’chaddr’ field in BOOTP messages, where 
‘chaddr’ is used both as a hardware address for transmission of BOOTP 
reply messages and as a client identifier. The ’client identifier’ 
option may contain a hardware address, identical to the contents of 
the ’chaddr’ field, or it may contain another type of identifier, 
such as a DNS name. Other client identifier types may be defined as 
needed for use with DHCP. New client identifier types will be 
registered with the IANA [18] and will be included in new revisions 
of the Assigned Numbers document, as well as described in detail in 
future revisions of the DHCP Options [2]. 
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0 1 2 3 
01234567890123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| op (1) | htype (1) | hlen (1) | hops (1) 
4+--------------- 4+--------------- 4+--------------- 4+--------------- + 
| xid (4) | 
$ oo 4------------------------------- + 
| secs (2) | flags (2) | 
4------------------------------- $ oo + 
| ciaddr (4) | 
$ = - -- $$ 5 5 5 5 5 5 = + 
| yiaddr (4) | 
$ -- = 5 $$ 5 5 5 5 = + 
| siaddr (4) | 
$ $5 5 5 5 = + 
| giaddr (4) | 
$ = -- -- $5 5 = + 
| | 
| chaddr (16) | 
| | 
| | 
$ -- - = 5 5 5 5 5 = + 
| | 
| sname (64) | 
$ = - -- - 5 $$ 5 5 5 5 = + 
| | 
| file (128) | 
$ = -- $$ 5 5 5 5 5 5 5 = + 
| | 
| options (312) | 
$ A $5 5 5 5 == + 
Figure 1: Format of a DHCP message 


DHCP clarifies the interpretation of the ’siaddr’ field as the 
address of the server to use in the next step of the client’s 
bootstrap process. A DHCP server may return its own address in the 
‘siaddr’ field, if the server is prepared to supply the next 
bootstrap service (e.g., delivery of an operating system executable 
image). A DHCP server always returns its own address in the 'server 
identifier’ option. 


The options field is now variable length, with the minimum extended 


to 312 octets. This brings the minimum size of a DHCP message up to 
576 octets, the minimum IP datagram size a host must be prepared to 
accept [3]. DHCP clients may negotiate the use of larger DHCP 


messages through the 'Maximum DHCP message size” option. The options 
field may be further extended into the ’file’ and 'sname” fields. 
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A new option, called 'vendor specific information’, has been added to 
allow for expansion of the number of options that can be supported 
[2]. Options encapsulated as 'vendor specific information’ must be 
carefully defined and documented so as to allow for interoperability 
between clients and servers from diferent vendors. In particular, 
vendors defining 'vendor specific information’ MUST document those 
options in the form of the DHCP Options document, MUST choose to 
represent those options either in data types already defined for DHCP 
options or in other well-defined data types, and MUST choose options 
that can be readily encoded in configuration files for exchange with 
servers provided by other vendors. Options included as 'vendor 
specific options’ MUST be readily supportable by all servers. 
LA EA TE 

0123456789012345 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
B| MBZ | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


B: BROADCAST flag 
MBZ: MUST BE ZERO (reserved for future use) 
Figure 2: Format of the ’flags’ field 


DHCP uses the 'flags” field [21]. The leftmost bit is defined as the 
BROADCAST (B) flag. The semantics of this flag are discussed in 
section 4.1 of this document. The remaining bits of the flags field 
are reserved for future use. They MUST be set to zero by clients and 
ignored by servers and relay agents. Figure 2 gives the format of 
the 'flags” field. 


2.1 Configuration parameters repository 


The first service provided by DHCP is to provide persistent storage 
of network parameters for network clients. The model of DHCP 
persistent storage is that the DHCP service stores a key-value entry 
for each client, where the key is some unique identifier (for 
example, an IP subnet number and a unique identifier within the 
subnet) and the value contains the configuration parameters for the 
client. 


For example, the key might be the pair (IP-subnet-number, hardware- 
address), allowing for serial or concurrent reuse of a hardware 
address on different subnets, and for hardware addresses that may not 
be globally unique. Alternately, the key might be the pair (IP- 
subnet-number, hostname), allowing the server to assign parameters 
intelligently to a host that has been moved to a different subnet or 
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has changed hardware addresses (perhaps because the network interface 
failed and was replaced). 


A client can query the DHCP service to retrieve its configuration 
parameters. The client interface to the configuration parameters 
repository consists of protocol messages to request configuration 
parameters and responses from the server carrying the configuration 
parameters. 


2.2 Dynamic allocation of network addresses 


The second service provided by DHCP is the allocation of temporary or 


permanent network (IP) addresses to hosts. The basic mechanism for 
the dynamic allocation of network addresses is simple: a client 
requests the use of an address for some period of time. The 


allocation mechanism (the collection of DHCP servers) guarantees not 
to reallocate that address within the requested time and attempts to 
return the same network address each time the client requests an 
address. In this document, the period over which a network address 
is allocated to a client is referred to as a "lease" [11]. The 
client may extend its lease with subsequent requests. The client may 
issue a message to release the address back to the server when the 
client no longer needs the address. The client may ask fora 
permanent assignment by asking for an infinite lease. Even when 
assigning "permanent" addresses, a server may choose to give out 
lengthy but non-infinite leases to allow detection of the fact that 
the host has been retired. 


In some environments it will be necessary to reassign network 
addresses due to exhaustion of available addresses. In such 
environments, the allocation mechanism will reuse addresses whose 
lease has expired. The server should use whatever information is 
available in the configuration information repository to choose an 
address to reuse. For example, the server may choose the least 
recently assigned address. As a consistency check, the allocation 
mechanism may probe the reused address, e.g., with an ICMP echo 
request, before allocating the address, and the client will probe the 
newly received address, e.g., with ARP. 


3. The Client-Server Protocol 


DHCP uses the BOOTP message format defined in RFC 951 and given in 
table 1 and figure 1. The 'op” field of each DHCP message sent from 
a client to a server contains BOOTREQUEST. BOOTREPLY is used in the 
‘op’ field of each DHCP message sent from a server to a client. 


The first four octets of the ’options’ field of the DHCP message 
contain the (decimal) values 99, 130, 83 and 99, respectively (this 
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is the same magic cookie as is defined in RFC 1497). The remainder 
of the “options” field consists a list of tagged parameters that are 
called "options". All of the "vendor extensions" listed in RFC 1497 


are also DHCP options. A separate document gives the complete set of 
options defined for use with DHCP [2]. 


Several options have been defined so far. One particular option - 
the "DHCP message type" option - must be included in every DHCP 
message. This option defines the "type" of the DHCP message. 
Additional options may be allowed, required, or not allowed, 
depending on the DHCP message type. 


Throughout this document, DHCP messages that include a ’DHCP message 
type’ option will be referred to by the type of the message; e.g., a 
DHCP message with ’DHCP message type’ option type 1 will be referred 
to as a "DHCPDISCOVER" message. 


3.1 Client-server interaction - allocating a network address 


The following summary of the protocol exchanges between clients and 


servers refers to the DHCP messages described in table 2. The 
timeline diagram in figure 3 shows the timing relationships in a 
typical client-server interaction. If the client already knows its 


address, some steps may be omitted; this abbreviated interaction is 
described in section 3.2. 


1. The client broadcasts a DHCPDISCOVER message on its local physical 
subnet. The DHCPDISCOVER message may include options that suggest 
values for the network address and lease duration. BOOTP relay 
agents may pass the message on to DHCP servers not on the same 
physical subnet. 


2. Each server may respond with a DHCPOFFER message that includes an 
available network address in the ’yiaddr’ field (and other 
configuration parameters in DHCP options). Servers need not 
reserve the offered network address, although the protocol will 
work more efficiently if the server avoids allocating the offered 
network address to another client. The server unicasts the 
DHCPOFFER message to the client (using the DHCP/BOOTP relay agent 
if necessary) if possible, or may broadcast the message to a 
broadcast address (preferably 255.255.255.255) on the client's 
subnet. 


3. The client receives one or more DHCPOFFER messages from one or 
more servers. The client may choose to wait for multiple 
responses. The client chooses one server from which to request 
configuration parameters, based on the configuration parameters 
offered in the DHCPOFFER messages. The client broadcasts a 
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Droms 


DHCPREQUEST message that MUST include the 'server identifier’ 
option to indicate which server it has selected, and may include 
other options specifying desired configuration values. This 
DHCPREQUEST message is broadcast and relayed through DHCP/BOOTP 
relay agents. To help ensure that any DHCP/BOOTP relay agents 
forward the DHCPREQUEST message to the same set of DHCP servers 
that received the original DHCPDISCOVER message, the DHCPREQUEST 
message must use the same value in the DHCP message header’s 
‘secs’ field and be sent to the same IP broadcast address as the 
original DHCPDISCOVER message. The client times out and 
retransmits the DHCPDISCOVER message if the client receives no 
DHCPOFFER messages. 


The servers receive the DHCPREQUEST broadcast from the client. 
Those servers not selected by the DHCPREQUEST message use the 
message as notification that the client has declined that server’s 
offer. The server selected in the DHCPREQUEST message commits the 
binding for the client to persistent storage and responds with a 
DHCPACK message containing the configuration parameters for the 
requesting client. The combination of 'chaddr” and assigned 
network address constitute an unique identifier for the client’s 
lease and are used by both the client and server to identify a 
lease referred to in any DHCP messages. The ’yiaddr’ field in the 
DHCPACK messages is filled in with the selected network address. 


If the selected server is unable to satisfy the DHCPREQUEST message 
(e.g., the requested network address has been allocated), the 
server SHOULD respond with a DHCPNAK message. 


A server may choose to mark addresses offered to clients in 
DHCPOFFER messages as unavailable. The server should mark an 
address offered to a client in a DHCPOFFER message as available if 
the server receives no DHCPREQUEST message from that client. 
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FIELD OCTETS DESCRIPTION 

op 1 Message op code / message type. 

1 = BOOTREQUEST, 2 = BOOTREPLY 

htype 1 Hardware address type, see ARP section in "Assigned 
Numbers" RFC; e.g., '1’ = 10mb ethernet. 

hlen 1 Hardware address length (e.g. ‘'’6’ for 10mb 
ethernet). 

hops 1 Client sets to zero, optionally used by relay-agents 
when booting via a relay-agent. 

xid 4 Transaction ID, a random number chosen by the 
client, used by the client and server to associate 
messages and responses between a client anda 
server. 

secs 2 Filled in by client, seconds elapsed since client 
started trying to boot. 

flags 2 Flags (see figure 2). 

ciaddr 4 Client IP address; filled in by client in 
DHCPREQUEST if verifying previously allocated 
configuration parameters. 

yiaddr 4 ‘your’ (client) IP address. 

siaddr 4 IP address of next server to use in bootstrap; 
returned in DHCPOFFER, DHCPACK and DHCPNAK by 
server. 

giaddr 4 Relay agent IP address, used in booting via a 
relay-agent. 

chaddr 16 Client hardware address. 

sname 64 Optional server host name, null terminated string. 

file 128 Boot file name, null terminated string; "generic" 
name or null in DHCPDISCOVER, fully qualified 
directory-path name in DHCPOFFER. 

options 312 Optional parameters field. See the options 
documents for a list of defined options. 

Table 1: Description of fields in a DHCP message 
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Server Client Server 
(not selected) (selected) 
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Begins initialization 
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| | 
| | 
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/ DHCPDISCOVER | DHCPDISCOVER | 


configuration configuration 


\ / 


\ /DHCPOFFER 


DHCPOFFER\ / 
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| 
| 
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| 

| 

| 
Collects replies | 
\| | 
| 

| 


Selects configuration 


| 
/\\ 
DHCPREQUEST \ 


| Commits configuration 


| | 
| / 
| 
| 


/ DHCPACK 


| 

| 

| 

| 

| 

| / DHCPREQUEST 
| 

| 

| 

| Initialization complete 
| 


Graceful shutdown 


| | 

| | \ | 

| | DHCPRELEASE \| 

| | 

| Discards lease 
vV vV vV 


Figure 3: Timeline diagram of messages exchanged between DHCP 
client and servers when allocating a new network address 


Droms [Page 15] 


RFC 1541 Dynamic Host Configuration Protocol October 1993 


DHCPDISCOVER 


Message Use 


Client broadcast to locate available servers. 


DHCPOFFER - Server to client in response to DHCPDISCOVER with 


offer of configuration parameters. 


DHCPREQUEST - Client broadcast to servers requesting offered 


parameters from one server and implicitly declining 
offers from all others. 


DHCPACK - Server to client with configuration parameters, 


including committed network address. 


DHCPNAK - Server to client refusing request for configuration 
parameters (e.g., requested network address already 
allocated). 

DHCPDECLINE - Client to server indicating configuration parameters 


(e.g., network address) invalid. 


DHCPRELEASE - Client to server relinquishing network address and 
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cancelling remaining lease. 
Table 2: DHCP messages 


The client receives the DHCPACK message with configuration 
parameters. The client performs a final check on the parameters 
(e.g., ARP for allocated network address), and notes the duration 
of the lease and the lease identification cookie specified in the 
DHCPACK message. At this point, the client is configured. If the 
client detects a problem with the parameters in the DHCPACK 
message, the client sends a DHCPDECLINE message to the server and 
restarts the configuration process. The client should wait a 
minimum of ten seconds before restarting the configuration process 
to avoid excessive network traffic in case of looping. 


If the client receives a DHCPNAK message, the client restarts the 
configuration process. 


The client times out and retransmits the DHCPREQUEST message if the 


client receives neither a DHCPACK or a DHCPNAK message. The client 
retransmits the DHCPREQUEST according to the retransmission 
algorithm in section 4.1. If the client receives neither a DHCPACK 


or a DHCPNAK message after ten retransmissions of the DHCPREQUEST 
message, the client reverts to INIT state and restarts the 
initialization process. The client SHOULD notify the user that the 
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initialization process has failed and is restarting. 


6. The client may choose to relinquish its lease on a network address 
by sending a DHCPRELEASE message to the server. The client 
identifies the lease to be released by including its network 
address in the 'ciaddr” field and its hardware address in the 
‘chaddr’ field. 


3.2 Client-server interaction - reusing a previously allocated network 
address 


If a client remembers and wishes to reuse a previously allocated 
network address (allocated either by DHCP or some means outside the 
protocol), a client may choose to omit some of the steps described in 
the previous section. The timeline diagram in figure 4 shows the 
timing relationships in a typical client-server interaction for a 
client reusing a previously allocated network address. 


Ts 
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The client broadcasts a DHCPREQUEST message on its local subnet. 
The DHCPREQUEST message includes the client’s network address in 
the 'ciaddr” field. DHCP/BOOTP relay agents pass the message on 
to DHCP servers not on the same subnet. 


Servers with knowledge of the client's configuration parameters 
respond with a DHCPACK message to the client. 


If the client's request is invalid (e.g., the client has moved 
to a new subnet), servers may respond with a DHCPNAK message to 
the client. 


The client receives the DHCPACK message with configuration 
prameters. The client performs a final check on the parameters 
(as in section 3.1), and notes the duration of the lease and 
the lease identification cookie specified in the DHCPACK 
message. At this point, the client is configured. 


If the client detects a problem with the parameters in the 
DHCPACK message, the client sends a DHCPDECLINE message to the 
server and restarts the configuration process by requesting a 
new network address. This action corresponds to the client 
moving to the INIT state in the DHCP state diagram, which is 
described in section 4.4. 
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Server Client Server 
v v v 
| | | 
| Begins | 
| initialization | 
| | | 
| IN | 
/ \ 
/DHCPREQUEST DHCPREQUEST\ 
| / | \| 
| | | 
Locates | Locates 
configuration | configuration 
| | | 
` / 
\ tene e 
| \ | / DHCPACK | 
k A | / | 
| DHCPACK\ | | 
| Initialization | 
| complete 
\| 

| | | 
| (Subsequent | 
| DHCPACKS | 
| ignored) | 
v v v 


Figure 4: Timeline diagram of messages exchanged between DHCP 
client and servers when reusing a previously allocated 
network address 


If the client receives a DHCPNAK message, it cannot reuse its 
remembered network address. It must instead request a new 
address by restarting the configuration process, this time 
using the (non-abbreviated) procedure described in section 
3.1. This action also corresponds to the client moving to 
the INIT state in the DHCP state diagram. 


The client times out and retransmits the DHCPREQUEST message if 
the client receives neither a DHCPACK nor a DHCPNAK message. 
The time between retransmission MUST be chosen according to 
the algorithm given in section 4.1. If the client receives no 
answer after transmitting 4 DHCPREQUEST messages, the client 
MAY choose to use the previously allocated network address and 


Droms [Page 18] 


RFC 1541 Dynamic Host Configuration Protocol October 1993 


configuration parameters for the remainder of the unexpired 
lease. This corresponds to moving to BOUND state in the client 
state transition diagram shown in figure 5. 


4. The client may choose to relinquish its lease on a network 
address by sending a DHCPRELEASE message to the server. The 
client identifies the lease to be released with the lease 
identification cookie. 


Note that in this case, where the client retains its network 
address locally, the client will not normally relinquish its 
lease during a graceful shutdown. Only in the case where the 
client explicitly needs to relinquish its lease, e.g., the client 
is about to be moved to a different subnet, will the client send 
a DHCPRELEASE message. 


3.3 Interpretation and representation of time values 


A client acquires a lease for a network address for a fixed period of 
time (which may be infinite). Throughout the protocol, times are to 
be represented in units of seconds. The time value of Oxffffffff is 
reserved to represent "infinity". The minimum lease duration is one 
hour. 


As clients and servers may not have synchronized clocks, times are 
represented in DHCP messages as relative times, to be interpreted 
with respect to the client’s local clock. Representing relative 
times in units of seconds in an unsigned 32 bit word gives a range of 
relative times from 0 to approximately 100 years, which is sufficient 
for the relative times to be measured using DHCP. 


The algorithm for lease duration interpretation given in the previous 
paragraph assumes that client and server clocks are stable relative 
to each other. If there is drift between the two clocks, the server 
may consider the lease expired before the client does. To 
compensate, the server may return a shorter lease duration to the 
client than the server commits to its local database of client 
information. 


3.4 Host parameters in DHCP 


Not all clients require initialization of all parameters listed in 
Appendix A. Two techniques are used to reduce the number of 
parameters transmitted from the server to the client. First, most of 
the parameters have defaults defined in the Host Requirements RFCs; 
if the client receives no parameters from the server that override 
the defaults, a client uses those default values. Second, in its 
initial DHCPDISCOVER or DHCPREQUEST message, a client may provide the 
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server with a list of specific parameters the client is interested 
Ts, 


The client SHOULD include the “maximum DHCP message size’ option to 
let the server know how large the server may make its DHCP messages. 
The parameters returned to a client may still exceed the space 
allocated to options in a DHCP message. In this case, two additional 
options flags (which must appear in the ’options’ field of the 
message) indicate that the ’file’ and ’sname’ fields are to be used 
for options. 


The client can inform the server which configuration parameters the 
client is interested in by including the 'parameter request list’ 
option. The data portion of this option explicitly lists the options 
requested by tag number. 


In addition, the client may suggest values for the network address 
and lease time in the DHCPDISCOVER message. The client may include 
the 'requested IP address” option to suggest that a particular IP 
address be assigned, and may include the ’IP address lease time’ 
option to suggest the lease time it would like. No other options 
representing "hints" at configuration parameters are allowed in a 
DHCPDISCOVER or DHCPREQUEST message. The 'ciaddr” field is to be 
filled in only in a DHCPREQUEST message when the client is requesting 
use of a previously allocated IP address. 


If a server receives a DHCPREQUEST message with an invalid 'ciaddr', 
the server SHOULD respond to the client with a DHCPNAK message and 
may choose to report the problem to the system administrator. The 
server may include an error message in the ’message’ option. 


3.5 Use of DHCP in clients with multiple interfaces 


A host with multiple network interfaces must use DHCP through each 
interface independently to obtain configuration information 
parameters for those separate interfaces. 


3.6 When clients should use DHCP 


A host should use DHCP to reacquire or verify its IP address and 
network parameters whenever the local network parameters may have 
changed; e.g., at system boot time or after a disconnection from the 
local network, as the local network configuration may change without 
the host’s or user’s knowledge. 


If a host has knowledge of a previous network address and is unable 
to contact a local DHCP server, the host may continue to use the 
previous network address until the lease for that address expires. 
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If the lease expires before the host can contact a DHCP server, the 
host must immediately discontinue use of the previous network address 
and may inform local users of the problem. 


4. Specification of the DHCP client-server protocol 


In this section, we assume that a DHCP server has a block of network 
addresses from which it can satisfy requests for new addresses. Each 
server also maintains a database of allocated addresses and leases in 
local permanent storage. 


4.1 Constructing and sending DHCP messages 


DHCP clients and servers both construct DHCP messages by filling in 
fields in the fixed format section of the message and appending 
tagged data items in the variable length option area. The options 
area includes first a four-octet 'magic cookie’ (which was described 
in section 3), followed by the options. The last option must always 
be the ’end’ option. 


DHCP uses UDP as its transport protocol. DHCP messages from a client 
to a server are sent to the 'DHCP server” port (67), and DHCP 
messages from a server to a client are sent to the ’DHCP client’ port 
(68). 


DHCP messages broadcast by a client prior to that client obtaining 
its IP address must have the source address field in the IP header 
set to 0. 


If the ’giaddr’ field in a DHCP message from a client is non-zero, 
the server sends any return messages to the ’DHCP server’ port on the 
DHCP relaying agent whose address appears in 'giaddr'. If the 
‘giaddr’ field is zero, the client is on the same subnet, and the 
server sends any return messages to either the client’s network 
address, if that address was supplied in the ’ciaddr’ field, or to 
the client’s hardware address or to the local subnet broadcast 
address. 


If the options in a DHCP message extend into the ’sname’ and ’ file’ 
fields, the 'option overload’ option MUST appear in the ‘options’ 
field, with value 1, 2 or 3, as specified in the DHCP options 
document [2]. If the ’option overload’ option is present in the 
‘options’ field, the options in the 'options” field MUST be 
terminated by an ’end’ option, and MAY contain one or more ’pad’ 
options to fill the options field. The options in the ’sname’ and 
“file” fields (if in use as indicated by the ’options overload’ 
option) MUST begin with the first octet of the field, MUST be 
terminated by an ’end’ option, and MUST be followed by 'pad” options 
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to fill the remainder of the field. Any individual option in the 
‘options’, '*sname” and ’file’ fields MUST be entirely contained in 
that field. The options in the ’options’ field MUST be interpreted 
first, so that any 'option overload’ options may be interpreted. The 
“file” field MUST be interpreted next (if the ’option overload’ 
option indicates that the ’file’ field contains DHCP options), 
followed by the ’sname’ field. 


DHCP clients are responsible for all message retransmission. The 
client MUST adopt a retransmission strategy that incorporates a 
randomized exponential backoff algorithm to determine the delay 
between retransmissions. The delay before the first retransmission 
MUST be 4 seconds randomized by the value of a uniform random number 
chosen from the range -1 to +1. Clients with clocks that provide 
resolution granularity of less than one second may choose a non- 
integer randomization value. The delay before the next 
retransmission MUST be 8 seconds randomized by the value of a uniform 
number chosen from the range -1 to +1. The retransmission delay MUST 
be doubled with subsequent retransmissions up to a maximum of 64 
seconds. The client MAY provide an indication of retransmission 
attempts to the user as an indication of the progress of the 
configuration process. The protocol specification in the remainder 
of this section will describe, for each DHCP message, when it is 
appropriate for the client to retransmit that message forever, and 
when it is appropriate for a client to abandon that message and 
attempt to use a different DHCP message. 


Normally, DHCP servers and BOOTP relay agents attempt to deliver 
DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using 
unicast delivery. The IP destination address (in the IP header) is 
set to the DHCP 'yiaddr” address and the link-layer destination 
address is set to the DHCP ’chaddr’ address. Unfortunately, some 
client implementations are unable to receive such unicast IP 
datagrams until the implementation has been configured with a valid 
IP address (leading to a deadlock in which the client’s IP address 
cannot be delivered until the client has been configured with an IP 
address). 


A client that cannot receive unicast IP datagrams until its protocol 
software has been configured with an IP address SHOULD set the 
BROADCAST bit in the ’flags’ field to 1 in any DHCPDISCOVER or 
DHCPREQUEST messages that client sends. The BROADCAST bit will 
provide a hint to the DHCP server and BOOTP relay agent to broadcast 
any messages to the client on the client’s subnet. A client that can 
receive unicast IP datagrams before its protocol software has been 
configured SHOULD clear the BROADCAST bit to 0. The BOOTP 
clarifications document discusses the ramifications of the use of the 
BROADCAST bit [21]. 


Droms [Page 22] 


RFC 1541 Dynamic Host Configuration Protocol October 1993 


A server or relay agent sending or relaying a DHCP message directly 
to a DHCP client (i.e., not to a relay agent specified in the 
'giaddr’ field) SHOULD examine the BROADCAST bit in the 'flags” 
field. If this bit is set to 1, the DHCP message SHOULD be sent as 
an IP broadcast using an IP broadcast address (preferably 
255.255.255.255) as the IP destination address and the link-layer 
broadcast address as the link-layer destination address. If the 
BROADCAST bit is cleared to 0, the message SHOULD be sent as an IP 
unicast to the IP address specified in the 'yiaddr” field and the 
link-layer address specified in the ’chaddr’ field. If unicasting is 
not possible, the message MAY be sent as an IP broadcast using an IP 
broadcast address (preferably 255.255.255.255) as the IP destination 
address and the link-layer broadcast address as the link-layer 
destination address. 


4.2 DHCP server administrative controls 


DHCP servers are not required to respond to every DHCPDISCOVER and 
DHCPREQUEST message they receive. For example, a network 
administrator, to retain stringent control over the hosts attached to 
the network, may choose to configure DHCP servers to respond only to 
hosts that have been previously registered through some external 
mechanism. The DHCP specification describes only the interactions 
between clients and servers when the clients and servers choose to 
interact; it is beyond the scope of the DHCP specification to 
describe all of the administrative controls that system 
administrators might want to use. Specific DHCP server 
implementations may incorporate any controls or policies desired by a 
network administrator. 


In some environments, a DHCP server will have to consider the values 
of the 'chaddr” field and/or the 'class-identifier” option included 
in the DHCPDISCOVER or DHCPREQUEST messages when determining the 
correct parameters for a particular client. For example, an 
organization might have a separate bootstrap server for each type of 
client it uses, requiring the DHCP server to examine the 'class- 
identifier’ to determine which bootstrap server address to return in 
the ’siaddr’ field of a DHCPOFFER or DHCPACK message. 


A DHCP server must use some unique identifier to associate a client 
with its lease. The client may choose to explicitly provide the 
identifier through the 'client identifier’ option. If the client 
does not provide a ‘client identifier’ option, the server MUST use 
the contents of the ’chaddr’ field to identify the client. 


DHCP clients are free to use any strategy in selecting a DHCP server 


among those from which the client receives a DHCPOFFER message. The 
client implementation of DHCP should provide a mechanism for the user 
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to select directly the 'class-identifier” value. 
4.3 DHCP server behavior 


A DHCP server processes incoming DHCP messages from a client based on 
the current state of the binding for that client. A DHCP server can 
receive the following messages from a client: 


o DHCPDISCOVER 
o DHCPREQUEST 
o DHCPDECLINE 
o DHCPRELEASE 


Table 3 gives the use of the fields and options in a DHCP message by 
a server. The remainder of this section describes the action of the 
DHCP server for each possible incoming message. 


4.3.1 DHCPDISCOVER message 


When a server receives a DHCPDISCOVER message from a client, the 
server chooses a network address for the requesting client. If no 
address is available, the server may choose to report the problem to 
the system administrator and may choose to reply to the client with a 
DHCPNAK message. If the server chooses to respond to the client, it 
may include an error message in the 'message” option. If an address 
is available, the new address should be chosen as follows: 


o The client’s previous address as recorded in the client’s binding, 
if that address is in the server’s pool of available addresses and 


not already allocated, else 


o The address requested in the ’Requested IP Address’ option, if that 
address is valid and not already allocated, else 


o A new address allocated from the server’s pool of available 
addresses. 
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Field DHCPOFFER DHCPACK DHCPNAK 
‘op’ BOOTREPLY BOOTREPLY BOOTREPLY 
"htype' (From "Assigned Numbers" RFC) 
"hlen’ (Hardware address length in octets) 
‘hops’ 0 0 0 
xd” “xid” from client “xid” from client “xid” from client 
DHCPDISCOVER DHCPREQUEST DHCPREQUEST 
message message message 
‘secs’ 0 0 0 
"ciaddr’ 0 "ciaddr” from "ciaddr” from 
DHCPREQUEST or 0 DHCPREQUEST or 0 
'yiaddr’ IP address offered IP address 0 
to client assigned to client 
'siaddr’ IP address of next IP address of next 0 
bootstrap server bootstrap server 
‘flags’ if 'giaddr” is not 0 then 'flags” from client message else 0 
"giaddr” 0 0 0 
* chaddr” *chaddr” from *chaddr” from *chaddr” from 
client client DHCPREQUEST client DHCPREQUEST 
DHCPDISCOVER message message 
message 
’ sname’ Server host name Server host name (unused) 
or options or options 
‘file’ Client boot file Client boot file (unused) 
name or options name or options 
‘options’ options options 
Option DHCPOFFER DHCPACK DHCPNAK 
Requested IP address MUST NOT MUST NOT MUST NOT 
IP address lease time MUST MUST MUST NOT 
Use 'file' /'sname' MAY MAY MUST NOT 
fields 
DHCP message type DHCPOFFER DHCPACK DHCPNAK 
Parameter request list MUST NOT MUST NOT MUST NOT 
Message SHOULD SHOULD SHOULD 
Client identifier MUST NOT MUST NOT MUST NOT 
Class identifier MUST NOT MUST NOT MUST NOT 
Server identifier MUST MAY MAY 
Maximum message size MUST NOT MUST NOT MUST NOT 
All others MAY MAY MUST NOT 
Table 3: Fields and options used by DHCP servers 
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As described in section 4.2, a server MAY, for administrative 
reasons, assign an address other than the one requested, or may 
refuse to allocate an address to a particular client even though free 
addresses are available. 


While not required for correct operation of DHCP, the server should 
not reuse the selected network address before the client responds to 
the server’s DHCPOFFER message. The server may choose to record the 
address as offered to the client. 


The server must also choose an expiration time for the lease, as 
follows: 


o IF the client has not requested a specific lease in the 
DHCPDISCOVER message and the client already has an assigned network 
address, the server returns the lease expiration time previously 
assigned to that address (note that the client must explicitly 
request a specific lease to extend the expiration time ona 
previously assigned address), ELSE 


o IF the client has not requested a specific lease in the 
DHCPDISCOVER message and the client does not have an assigned 
network address, the server assigns a locally configured default 
lease time, ELSE 


o IF the client has requested a specific lease in the DHCPDISCOVER 
message (regardless of whether the client has an assigned network 
address), the server may choose either to return the requested 
lease (if the lease is acceptable to local policy) or select 
another lease. 


Once the network address and lease have been determined, the server 
constructs a DHCPOFFER message with the offered configuration 
parameters. It is important for all DHCP servers to return the same 
parameters (with the possible exception of a newly allocated network 
address) to ensure predictable host behavior regardless of the which 
server the client selects. The configuration parameters MUST be 
selected by applying the following rules in the order given below. 
The network administrator is responsible for configuring multiple 
DHCP servers to ensure uniform responses from those servers. The 
server MUST return to the client: 
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The client's network address, as determined by the rules given 
earlier in this section, and the subnet mask for the network to 
which the client is connected, 


The expiration time for the client's lease, as determined by the 
rules given earlier in this section, 


Parameters requested by the client, according to the following 
rules: 


—- IF the server has been explicitly configured with a default 
value for the parameter, the server MUST include that value 
in an appropriate option in the ’option’ field, ELSE 


—- IF the server recognizes the parameter as a parameter 
defined in the Host Requirements Document, the server MUST 
include the default value for that parameter as given in the 
Host Requirements Document in an appropriate option in the 
‘option’ field, ELSE 


-- The server MUST NOT return a value for that parameter, 


Any parameters from the existing binding that differ from the Host 
Requirements documents defaults, 


Any parameters specific to this client (as identified by 
the contents of 'chaddr” in the DHCPDISCOVER or DHCPREQUEST 
message), e.g., as configured by the network administrator, 


Any parameters specific to this client's class (as identified 
by the contents of the 'class identifier’ option in the 
DHCPDISCOVER or DHCPREQUEST message), e.g., as configured by 
the network administrator; the parameters MUST be identified 
by an exact match between the client's 'client class” and the 
client class identified in the server, 


Parameters with non-default values on the client’s subnet. 


The server inserts the 'xid” field from the DHCPDISCOVER message into 
the 'xid” field of the DHCPOFFER message and sends the DHCPOFFER 


me 


4.3.2 


A 


ssage to the requesting client. 
DHCPREQUEST message 


DHCPREQUEST message may come from a client responding to a 


DHCPOFFER message from a server, or from a client verifying a 
previously allocated IP address. If the DHCPREQUEST message contains 


a 
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DHCPOFFER message. Otherwise, the message is a request to renew or 
extend an existing lease. 


Consider first the case of a DHCPREQUEST message in response to a 
DHCPOFFER message. If the server is identified in the 'server 
identifier’ option in the DHCPREQUEST message, the server checks to 
confirm that the requested parameters are acceptable. Usually, the 
requested parameters will match those returned to the client in the 
DHCPOFFER message; however, the client may choose to request a 
different lease duration. Also, there is no requirement that the 
server cache the parameters from the DHCPOFFER message. The server 
must simply check that the parameters requested in the DHCPREQUEST 
are acceptable. If the parameters are acceptable, the server records 
the new client binding and returns a DHCPACK message to the client. 


If the requested parameters are unacceptable, e.g., the requested 
lease time is unacceptable to local policy, the server sends a 
DHCPNAK message to the client. The server may choose to return an 
error message in the ’/message’ option. 


If a different server is identified in the ’server identifier’ field, 
the client has selected a different server from which to obtain 
configuration parameters. The server may discard any information it 
may have cached about the client’s request, and may free the network 
address that it had offered to the client. 


Note that the client may choose to collect several DHCPOFFER messages 
and select the "best" offer. The client indicates its selection by 
identifying the offering server in the DHCPREQUEST message. If the 
client receives no acceptable offers, the client may choose to try 
another DHCPDISCOVER message. Therefore, the servers may not receive 
a specific DHCPREQUEST from which they can decide whether or not the 
client has accepted the offer. Because the servers have not 
committed any network address assignments on the basis of a 
DHCPOFFER, servers are free to reuse offered network addresses in 
response to subsequent requests. As an implementation detail, 
servers should not reuse offered addresses and may use an 
implementation-specific timeout mechanism to decide when to reuse an 
offered address. 


In the second case, when there is no 'server identifier’ option, the 
client is renewing or extending a previously allocated IP address. 
The server checks to confirm that the requested parameters are 
acceptable. If the parameters specified in the DHCPREQUEST message 
match the previous parameters, or if the request for an extension of 
the lease (indicated by an extended ’IP address lease time’ option) 
is acceptable, the server returns a DHCPACK message to the requesting 
client. Otherwise, the server returns a DHCPNAK message to the 
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client. In particular, if the previously allocated network address 
in the *ciaddr” field from the client does not match the network 
address recorded by the server for that client, the server sends a 
DHCPNAK to the client. 


A DHCP server chooses the parameters to return in a DHCPACK message 
according to the same rules as used in constructing a DHCPOFFER 
message, as given in section 4.3.1. 


4.3.3 DHCPDECLINE message 


If the server receives a DHCPDECLINE message, the client has 
discovered through some other means that the suggested network 
address is already in use. The server MUST mark the network address 
as not allocated and SHOULD notify the local system administrator of 
a possible configuration problem. 


4.3.4 DHCPRELEASE message 


Upon receipt of a DHCPRELEASE message, the server marks the network 

address as not allocated. The server should retain a record of the 

client’s initialization parameters for possible reuse in response to 
subsequent requests from the client. 


4.4 DHCP client behavior 


Figure 5 gives a state-transition diagram for a DHCP client. A 
client can receive the following messages from a server: 


o DHCPOFFER 
o DHCPACK 
o DHCPNAK 


Table 4 gives the use of the fields and options in a DHCP message by 
a client. The remainder of this section describes the action of the 
DHCP client for each possible incoming message. The description in 
the following section corresponds to the full configuration procedure 
previously described in section 3.1, and the text in the subsequent 
section corresponds to the abbreviated configuration procedure 
described in section 3.2. 


4.4.1 Initialization and allocation of network address 
The client begins in INIT state and forms a DHCPDISCOVER message. 


The client should wait a random time between one and ten seconds to 
desynchronize the use of DHCP at startup. The client sets ’ciaddr’ 
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to 0x00000000. The client MAY request specific parameters by 
including the 'parameter request list’ option. The client MAY 
suggest a network address and/or lease time by including the 
‘requested IP address’ and ’IP address lease time’ options. The 
client MUST include its hardware address in the ’chaddr’ field for 
use in delivery of DHCP reply messages. The client MAY include a 
different unique identifier in the 'client identifier’ option. If 
the client does not include the 'client identifier’ option, the 
server will use the contents of the ’chaddr’ field to identify the 
client’s lease. 


The client generates and records a random transaction identifier and 
inserts that identifier into the ’xid’ field. The client records its 
own local time for later use in computing the lease expiration. The 
client then broadcasts the DHCPDISCOVER on the local hardware 
broadcast address to Oxffffffff IP broadcast address and ’DHCP 
server’ UDP port. 


If the 'xid” of an arriving DHCPOFFER message does not match the 
'xid’ of the most recent DHCPDISCOVER message, the DHCPOFFER message 
must be silently discarded. Any arriving DHCPACK messages must be 
Silently discarded. 


The client collects DHCPOFFER messages over a period of time, selects 
one DHCPOFFER message from the (possibly many) incoming DHCPOFFER 
messages (e.g., the first DHCPOFFER message or the DHCPOFFER message 
from the previously used server) and extracts the server address from 
the 'server identifier’ option in the DHCPOFFER message. The time 
over which the client collects messages and the mechanism used to 
select one DHCPOFFER are implementation dependent. The client may 
perform a check on the suggested address to ensure that the address 
is not already in use. For example, if the client is on a network 
that supports ARP, the client may issue an ARP request for the 
suggested request. When broadcasting an ARP request for the 
suggested address, the client must fill in its own hardware address 
as the sender’s hardware address, and 0 as the sender’s IP address, 
to avoid confusing ARP caches in other hosts on the same subnet. If 
the network address appears to be in use, the client sends a 
DHCPDECLINE message to the server and waits for another DHCPOFFER. As 
the client does not have a valid network address, the client must 
broadcast the DHCPDECLINE message. 
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Figure 5: State-transition diagram for DHCP clients 
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Option DHCPDISCOVER DHCPREQUEST DHCPDECLINE, 
DHCPRELEASE 
Requested IP address MAY MUST NOT MUST NOT 
IP address lease time MAY MAY MUST NOT 
Use 'file'/'sname” fields MAY MAY MAY 
DHCP message type DHCPDISCOVER DHCPREQUEST DHCPDECLINE/ 
DHCPRELEASE 
Client identifier MAY MAY MAY 
Class identifier SHOULD SHOULD MUST NOT 
Server identifier MUST NOT MUST (after MUST 
DHCPDISCOVER), 
MUST NOT (when 
renewing) 
Parameter request list MAY MAY MUST NOT 
Maximum message size MAY MAY MUST NOT 
Message SHOULD NOT SHOULD NOT SHOULD 
Site-specific MAY MAY MUST NOT 
All others MUST NOT MUST NOT MUST NOT 


Table 4: Fields and options used by DHCP clients 

If the parameters are acceptable, the client records the address of 
the server that supplied the parameters from the 'server identifier’ 
field and sends that address in the ’server identifier’ field of a 
DHCPREQUEST broadcast message. Once the DHCPACK message from the 
server arrives, the client is initialized and moves to BOUND state. 
The DHCPREQUEST message contains the same 'xid” as the DHCPOFFER 
message. The client records the lease expiration time as the sum of 
the time at which the original request was sent and the duration of 
the lease from the DHCPOFFER message. The client SHOULD broadcast an 
ARP reply to announce the client’s new IP address and clear any 
outdated ARP cache entries in hosts on the client’s subnet. 


4.4.2 Initialization with known network address 


The client begins in INIT-REBOOT state and sends a DHCPREQUEST message 
with the ’ciaddr’ field set to the client’s network address. The 

client may request specific configuration parameters by including 

the 'parameter request list’ option. The client generates and records a 
random transaction identifier and inserts that identifier into the ’xid’ 
field. The client records its own local time for later use in 

computing the lease expiration. The client MUST NOT incldue a ’server 


identifier’ in the DHCPREQUEST message. The client then broadcasts 
the DHCPREQUEST on the local hardware broadcast address to the ’DHCP 
server’ UDP port. 
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Once a DHCPACK message with an 'xid” field matching that in the 
client’s DHCPREQUEST message arrives from any server, the client is 
initialized and moves to BOUND state. The client records the lease 
expiration time as the sum of the time at which the DHCPREQUEST 
message was sent and the duration of the lease from the DHCPACK 
message. 


4.4.3 Initialization with a known DHCP server address 


When the DHCP client knows the address of a DHCP server, in either 
INIT or REBOOTING state, the client may use that address in the 
DHCPDISCOVER or DHCPREQUEST rather than the IP broadcast address. If 
the client receives no response to DHCP messages sent to the IP 
address of a known DHCP server, the DHCP client reverts to using the 
IP broadcast address. 


4.4.4 Reacquisition and expiration 


The client maintains two times, Tl and T2, that specify the times at 
which the client tries to extend its lease on its network address. T1 
is the time at which the client enters the RENEWING state and attempts 
to contact the server that originally issued the client’s network 
address. T2 is the time at which the client enters the REBINDING 
state and attempts to contact any server. 


At time T1 after the client accepts the lease on its network address, 
the client moves to RENEWING state and sends (via unicast) a 
DHCPREQUEST message to the server to extend its lease. The client 
generates a random transaction identifier and inserts that identifier 
into the 'xid” field in the DHCPREQUEST. The client records the local 
time at which the DHCPREQUEST message is sent for computation of the 
lease expiration time. The client MUST NOT include a 'server 
identifier’ in the DHCPREQUEST message. 


Any DHCPACK messages that arrive with an ’xid’ that does not match 

the ’xid’ of the client's DHCPREQUEST message are silently discarded. 
When the client receives a DHCPACK from the server, the client 
computes the lease expiration time as the sum of the time at which the 
client sent the DHCPREQUEST message and the duration of the lease in 
the DHCPACK message. The client has successfully reacquired its 
network address, returns to BOUND state and may continue network 
processing. 


If no DHCPACK arrives before time T2 (T2 > T1) before the expiration 
of the client’s lease on its network address, the client moves to 
REBINDING state and sends (via broadcast) a DHCPREQUEST message to 
extend its lease. The client sets the ’ciaddr’ field in the 
DHCPREQUEST to its current network address. The client MUST NOT 
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include a 'server identifier’ in the DHCPREQUEST message. 


Times T1 and T2 are configurable by the server through options. T1 
defaults to (0.5 * duration_of_lease). T2 defaults to (0.875 * 
duration_of_lease). Times T1 and T2 should be chosen with some random 
"fuzz" around a fixed value, to avoid synchronization of client 
reacquisition. 


In both RENEWING and REBINDING state, if the client receives no 
response to its DHCPREQUEST message, the client should wait one-half 
the remaining time until the expiration of T1 (in RENEWING state) and 
T2 (in REBINDING state) down to a minimum of 60 seconds, before 
retransmitting the DHCPREQUEST message. 


If the lease expires before the client receives a DHCPACK, the client 
moves to INIT state, MUST immediately stop any other network 
processing and requests network initialization parameters as if the 


client were uninitialized. If the client then receives a DHCPACK 
allocating that client its previous network address, the client SHOULD 
continue network processing. If the client is given a new network 


address, it MUST NOT continue using the previous network address and 
SHOULD notify the local users of the problem. 


4.4.5 DHCPRELEASE 


If the client no longer requires use of its assigned network address 
(e.g., the client is gracefully shut down), the client sends a 
DHCPRELEASE message to the server. Note that the correct operation of 
DHCP does not depend on the transmission of DHCPRELEASE messages. 
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7. Security Considerations 


DHCP is built directly on UDP and IP which are as yet inherently 
insecure. Furthermore, DHCP is generally intended to make 
maintenance of remote and/or diskless hosts easier. While perhaps 
not impossible, configuring such hosts with passwords or keys may be 
difficult and inconvenient. Therefore, DHCP in its current form is 
quite insecure. 


Unauthorized DHCP servers may be easily set up. Such servers can 
then send false and potentially disruptive information to clients 
such as incorrect or duplicate IP addresses, incorrect routing 
information (including spoof routers, etc.), incorrect domain 
nameserver addresses (such as spoof nameservers), and so on. 
Clearly, once this seed information is in place, an attacker can 
further compromise affected systems. 


Malicious DHCP clients could masquerade as legitimate clients and 
retrieve information intended for those legitimate clients. Where 
dynamic allocation of resources is used, a malicious client could 
claim all resources for itself, thereby denying resources to 
legitimate clients. 
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A. Host Configuration Parameters 
IP-layer_parameters, _per_host:_ 


Be a router 

Non-local source routing 

Policy filters for 

non-local source routing 

Maximum reassembly size 

Default TTL 

PMTU aging timeout 

MTU plateau table 

IP-layer_parameters,_per_interf 

IP address 

Subnet mask 

MTU 

All-subnets-MTU 

Broadcast address flavor 

Perform mask discovery 

Be a mask supplier 

Perform router discovery 

Router solicitation address 

Default routers, list of: 
router address 
preference level 

Static routes, list of: 

destination 

destination mask 

type-of-service 

first-hop router 

ignore redirects 

PMTU 

perform PMTU discovery 


Link-layer_parameters,_per_inte 
Trailers 

ARP cache timeout 

Ethernet encapsulation 


TCP_parameters,_per_host:_ 
TTL 

Keep-alive interval 
Keep-alive data size 


Key: 


MTU = Path MTU Discovery (RFC 1 
RD = Router Discovery (RFC 1256 
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on/off 
on/off 


(list) 

integer 
integer 
integer 

(list) 
ace:_ 

(address) 
(address mask) 
integer 
on/off 
0x00000000/0xffffffff 
on/off 

on/off 

on/off 
(address) 


(address) 
integer 


(host/subnet/net) 
(address mask) 
integer 

(address) 

on/off 

integer 

on/off 


rface:_ 

on/off 

integer 

(RFC 894/RFC 1042) 


integer 
integer 
0/1 


191, Proposed Standard) 
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